Gail Shaw wrote:
> In theory, you want to prevent any form of data anomaly from multiple
> accesses. 

Or, in my examples, you only have one writer, and that writer is doing 
atomic writes, and no reader looks at multiple records in one 
transaction. So what's there to transactionify?

I have another table, where I have multiple processes going thru it, 
doing what it says to do, each step taking maybe 10-30 seconds. Rather 
than using a transactional table, I do things like
SELECT * from to_do where state = 3 limit 10
then for each of those rows, I do
UPDATE to_do SET state=4 WHERE id=$id AND state = 3
then I check if the num_rows_affected > 0, and if so, I know I'm the one 
that changed that row.  Just as an example. If the rows affected was 
zero, someone else changed that specific ID.

A bit kludgey, I'll admit, but better than holding a transactional lock 
on the table for 30 seconds at a time.

-- 
   Darren New / San Diego, CA, USA (PST)
     It's not feature creep if you put it
     at the end and adjust the release date.

Post a reply to this message